structured outputs
従来はこんな感じだった
code:res
承知しました。以下がjsonです
`json
{...
ここからjsonを取り出すのと、あと出来上がったjsonがvalidか分からんのと精度の問題があった
新しいモデルでは、精度がほぼ？100%でスキーマ通り出せるようになった
その精度をどうやって実現したかも気になるところだが、ユーザとしては知らなくても良い
情報をjsonで構造化できるので、アプリケーション上で適切に情報を取り出せるようになった
おもしろい例
センテンスごとにナンバーを付けて、AIや人間の指示に使う
パラグラフ、センテンス、フレーズ分解
かなりちゃんとできる
さらに、各々の構造に追加で命令が書ける
パラグラフの要約して、とか
実はschema自体もプロンプトに過ぎない
descriptionに説明を書くと、解釈される
LLMは順番に出力するため、先に答えを出したいpropertyを前に書くほうが、後続のプロパティを前者に従わせられる
先にcountなどを出力させてから、個別要素を出力させたり
gpt-4o-miniはなんか頭が悪くなってない？
gpt-4oならなんとか
要約って結構難しいタスクだな、という印象があるmiyamonz.icon
個人的には、まだ要約って一発でいい感じに出すプロンプトが分からん
文章に応じてどのように要約すべきかが違う気がする
あとそもそも、要約って目的や意図によって変わってくるし
まずは文章の構造化あたりから攻めるべきと感じている
schemaもpromptの一種
descriptionがpromptとして機能する
propertyの順序がchain of thoughtと同様に出力に差を与える
事前に確定しやすく、後の出力の補助になりそうなpropertyを先にする方が良い
なんでこんなことが実現できてるのだろう
under the foodのところ
出力時に可能なtokenを制限してる
しかし、{"valまで出力したら、もう{は出せない
つまり、出力可能tokenは動的
ここのために、JSON Schemaを文脈自由文法に変換している
tokenにマスクをかける形なのかな？
そう考えると、そのマスクのせいでLLMの性能が落ちないかというのはちょっと分かるかも
CoT的に自由に出力させた後に、そこからstructured outputsに引き回すと改善しそう
これならたしかにスキーマ精度が100%というのは理解できる